Notes:

• When point processing is performed on history data groups, only closed records will be published and processed to points. If a device has leading timestamped records and returns the current, open record, point processing will not be performed for that record, even though there is data in the DDS transaction. The point record will be updated only when that record is closed. This is to avoid a situation where a point has multiple entries with the same timestamp, since an open record may be still updating values with each new poll, but each update will have the same timestamp. For example, say you start polling for a daily history record at 8:00am, you’ll get the first value at 8:00am, then if you poll every five minutes, you’ll get new values throughout the day at the exact same timestamp. A history record is basically an array of data with a timestamp and values where the values have different process variables for each incremental poll. The timestamp won’t get written until the record is closed, which happens at the end of the time period, in this case, a day.

• Best practice recommends that you do not perform UDC and point processing on FMS data groups. The DEIDs specified in FMS data groups are generic and use the eFMS enumeration to identify the CygNet-defined FMS items referenced in the device template file. No polling is done on these data groups — all data is coming from the native data groups. Points should be mapped to the native data groups since that is the data group that is actually processing the device data. While point processing may work on the FMS data groups, it is not supported, not tested, not consistent across EIEs, and is not recommended practice.